Teil 1: Non-Human Identities zähmen – Schluss mit Credential-Chaos dank SPIFFE

Unternehmen führen hunderte Microservices, Serverless Functions und Container aus. Jeder dieser Workloads benötigt Zugangsdaten, um mit APIs, Datenbanken oder anderen Diensten zu kommunizieren. Dabei wächst die Zahl der Secrets – und mit ihnen das Risiko von Datenlecks, Fehlkonfigurationen oder Compliance-Verstößen. Doch eine Lösung, die plattformübergreifend, automatisch und überprüfbar arbeitet, fehlt in den meisten Organisationen. SPIFFE setzt hier an und eröffnet verschiedene Vorteile.

Drei Optionen – kein Mehrwert

Die täglichen Gefahren von nicht geschützten Non-Human Identities, kurz NHI, sind greifbar: vergessene API-Keys, falsch konfigurierte Service-Accounts, aufwendige Rotationen. Gleichzeitig binden sie Ressourcen, bringen schwer zu auditierende Zugriffe mit sich und verlangsamen Innovation. Die Frage ist also: Wie schaffen es Organisationen, Maschinen Identitäten ebenso sicher, skalierbar und automatisiert zu managen wie Benutzeridentitäten?

Lassen Sie uns dafür konkreter werden: Nehmen Sie an, dass Ihre Firma einen neuen Microservice bereitstellt, der sich bei drei verschiedenen APIs authentifizieren muss. Welche Optionen existieren, um den Microservice mit den notwendigen Authentifizierungsdaten (Credentials) auszustatten?

1. Unternehmen können API-Keys in einem Secret Vault speichern. Müssen sich in diesem Fall aber wiederum sicher am Secret Vault authentifizieren.

2. Sie können vordefinierte IAM-Rollen des Cloudanbieters verwenden. Müssen dann jedoch die Komplexität des Cloud-übergreifenden Zugriffs verwalten.

3. Verantwortliche können die Anmeldedaten manuell für jedes Maschinenkonto bereitstellen.

Das sind drei gängige Optionen. Doch mit steigender Zahl der Services gestaltet sich auch ihre Handhabung deutlich umständlicher.

Der Albtraum des Credential Bootstraps

Einem Workload – egal, ob es sich um einen Container, eine Serverless Function oder einen Batch-Job handelt – sicher die ersten Authentifizierungsdaten zu übergeben, ist demnach die zentrale Herausforderung. Selbst, wenn Unternehmen Tools zur Verwaltung von Zugangsdaten (Secrets Management ) verwenden, müssen sie immer noch das lästige Bootstrap-Problem lösen, wie sich ein Workload überhaupt beim Secrets Manager authentifizieren lässt. Dieses Henne-Ei-Problem beschäftigt Infrastrukturteams seit Jahrzehnten.

Die sichere Speicherung der Secrets ist dabei weniger herausfordernd als die initiale Verteilung. Die nächste – meist kopfzerbrechende – Frage schließt sich an: Wie erhält eine Workload das erste Geheimnis, wenn noch über keinerlei Authentifizierungsdaten verfügbar sind?

Traditionelle Ansätze, die Ihnen Probleme bereiten werden

Warum all diese Ausführungen – Ansätze zur Verwaltung von Maschinen-Identitäten existieren bereits. Sie haben recht! Doch diese sind wenig praktikabel. Noch schlimmer: Sie lösen das eigentliche Problem nur in Teilbereichen – Sicherheit und Effizienz büßen ein.

• Tools zur Verwaltung von Credentials: Der verantwortungsbewusste Ansatz besteht darin, API-Keys in HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault abzulegen. Damit stehen Sie vor dem bereits genannten Bootstrap-Problem: Wie authentifiziert sich der Workload beim Secrets Manager? Am Ende müssen Sie wieder Vault-Tokens, IAM-Rollen oder Service-Principal-Credentials verteilen.

• Cloud-IAM-Rollen und Kubernetes-Service-Accounts: Diese lösen das Bootstrap-Problem in ihren jeweiligen Domänen auf elegante Weise. AWS-IAM-Rollen für EC2-Instanzen, Google-Cloud-Service-Accounts für GKE-Workloads und Kubernetes-Service-Accounts stellen automatisch kryptografisch abgesicherte Identitäten bereit – ganz ohne vorab verteilte Secrets. Innerhalb ihrer Grenzen funktionieren sie hervorragend.

• Service-Account-Anmeldeinformationen: Klassische Authentifizierung per Benutzername/Passwort oder Zertifikat sind besser als fest im Code hinterlegte Secrets. Aber sie sind dennoch auf sichere Verteilungsmechanismen und Rotationsverfahren angewiesen.

• Umgebungsvariablen und mounted Secrets: Die Anmeldedaten werden nicht im Code hinterlegt, befinden sich aber weiterhin im Speicher, in Prozesslisten und möglicherweise in Protokollen. Außerdem muss jemand diese Umgebungsvariablen weiterhin sicher ausfüllen.

Aufgrund der Schwachstellen vervielfacht sich die Herausforderung mit jedem neuen Service, Container oder Deployment exponentiell. Was als “ein paar API-Keys” begann, wächst schnell zu hunderten oder tausenden von Anmeldedaten an, verstreut über die gesamte Infrastruktur – jedes einzelne davon ein mögliches Sicherheitsrisiko.

Die gute Nachricht: Es gibt einen Weg, Maschinen-Identitäten ohne das Credential-Chaos abzusichern. Genau hier setzt SPIFFE an.

SPIFFE – Gamechanger bei Authentifizierungsdaten

SPIFFE (Secure Production Identity Framework for Everyone) steht für einen grundlegenden Paradigmenwechsel. Unternehmen müssen sich nicht mehr fragen, wie Geheimnisse sicher verteilt werden. Stattdessen steht im Fokus: “Was wäre, wenn Workloads ihre Identität nachweisen könnten, ohne dass zuvor irgendwelche Secrets verteilt werden müssen?”

Der zentrale Gedanke, der alles verändert: Ihre Infrastruktur weiß bereits, wo Workloads laufen und wie sie dorthin gelangt sind. SPIFFE nutzt dieses vorhandene Wissen, um automatisch kryptografisch überprüfbare Identitäten zu erstellen.

Beispiele aus der Praxis: Wenn in Kubernetes ein Container startet, kennt die Plattform den zugehörigen Service-Account, das Namespace und den Node, auf dem er läuft. Wenn eine Lambda-Funktion ausgeführt wird, weiß AWS genau, welche Rolle sie übernimmt und wie sie aufgerufen wurde. SPIFFE wandelt dieses Plattformwissen in fälschungssichere Workload-Identitäten um – ohne dass zuvor Zugangsdaten bzw. Anmeldedaten verteilt werden müssen.

---

ℹ️ SPIFFE: Wann ist der Open-Source-Standard sinnvoll?

Unsere ehrliche Einschätzung: Wenn Sie ausschließlich in einer einzelnen Cloud arbeiten und einfache Workload-Muster zugrunde liegen, sind Cloud-native IAM-Mechanismen oft völlig ausreichend. SPIFFE wird dann interessant, wenn mehrere Identitätsdomänen miteinander verbunden werden müssen oder wenn Sie eine zukunftssichere Grundlage suchen, die nicht an das Ökosystem eines einzelnen Anbieters gebunden ist.

---

Wie SPIFFE das Bootstrap-Problem löst

Die zugrundliegende Magie lautet Attestation und funktioniert wie folgt:

• Keine Credentials beim Deployment: Der Workload startet ohne jegliche Vorabdaten – keine API-Keys, keine Passwörter, keine eingebetteten Zertifikate.

• Plattformüberprüfung: Das SPIFFE-System (bereitgestellt durch die von der Cloud Native Computing Foundation entwickelte Lösung SPIRE oder kommerziell von SPIRL nutzt plattformspezifische Mechanismen, um zu prüfen, ob der Workload tatsächlich das ist, was er vorgibt zu sein. In Kubernetes kann dies die Validierung von Pod-Metadaten oder Service-Account-Tokens sein; in AWS die Überprüfung des “Instance Identity Document”.

• Identitätsüberprüfung auf Prozessebene: Anders als Cloud-IAM-Rollen oder Kubernetes-Service-Accounts, die für jeden Prozess auf einer VM oder in einem Container verfügbar sind, kann SPIFFE über seine Workload-API einzelne Prozesse authentifizieren. Nur die spezifische Anwendung, die Authentifizierungsdaten benötigt, erhält diese – selbst, wenn mehrere Prozesse auf demselben Host oder Container laufen.

• Automatische Bereitstellung der Identität: Nach der Verifikation erhält der Workload ein kryptografisch signiertes Identitätsdokument (SVID – SPIFFE Verifiable Identity Document), das die Identität nachweist. Dieses liegt in Standardformaten vor – entweder als X.509-Zertifikat oder JWT-Token – und ist damit mit bestehenden Systemen kompatibel, die diese Standardformate unterstützen.

• Erweiterte Sicherheitsüberprüfung: SPIFFE kann zusätzliche Ebenen der Workload-Authentizität überprüfen, die über die Plattformidentität hinausgehen. Dazu gehören die Signaturvalidierung von Container-Images (über Sigstore/Cosign), die Prüfung des ausführbaren Pfads sowie SHA256-Prüfsummen der Binary des aufrufenden Prozesses. So wird sichergestellt, dass nur autorisierter, unveränderter Code Identitäten erhält.

• Kurzlebige Authentifizierungsdaten mit automatischer Rotation: Diese Identitäten laufen schnell ab (typischerweise nach wenigen Stunden) und werden automatisch erneuert. Kein manueller Rotationsplan, keine vergessenen Authentifizierungsdaten, die monatelang herumliegen.

• Universelles Vertrauen: Dieselbe Identität kann zur Authentifizierung bei APIs, Datenbanken, Service-Meshes und jedem anderen System verwendet werden, das SPIFFE-Identitäten (X.509 oder JWT) versteht.

Diese prozessgenaue Granularität ist besonders wertvoll in Szenarien, in denen mehrere Anwendungen auf derselben VM oder im selben Container laufen – oder wenn sichergestellt werden soll, dass nur der Hauptprozess einer Anwendung, nicht aber Sidecars, Debug-Tools oder andere Hilfsprogramme, Zugriff auf sensible Authentifizierungsdaten erhalten.

Man kann sich das wie ein digitales Passsystem für Prozesse vorstellen: Jede Anwendung erhält eine fälschungssichere ID, die sowohl nachweist, wer sie ist, als auch, dass sie an einem autorisierten Ort ausgeführt wird – und das ganz ohne statische Authentifizierungsdaten.

SPIFFE als grundlegende Komponente für Machine IAM

SPIFFE ist nicht zwingend das zentrale Element einer Machine-IAM-Architektur, kann jedoch als wichtige Basis dienen, auf der andere Werkzeuge aufbauen. Es fungiert als universeller Mechanismus, der die Interoperabilität verschiedener Tools ermöglicht.

Integration mit Service-Meshes: Service Meshes wie Istio oder Linkerd können SPIFFE-Identitäten nutzen, um die Kommunikation zwischen Services automatisch abzusichern. Ein manuelles Zertifikatsmanagement oder der Einsatz geteilter Geheimnisse entfällt.

Einfache OAuth-Integration: SPIFFE-Identitäten können direkt als OAuth-Client-Credentials verwendet werden. Workloads authentifizieren sich mithilfe ihrer SPIFFE-Identität bei OAuth-Providern, ohne dass separate Client-Secrets verwaltet werden müssen.

API-Gateway-Authentifizierung: Anstelle statischer API-Keys können Workloads ihre dynamisch erzeugten SPIFFE-Identitäten für die Authentifizierung gegenüber API-Gateways verwenden. Diese prüfen die Identität anhand zuvor definierter Vertrauensrichtlinien.

Zugriff auf Datenbanken und Infrastruktur: Viele moderne Datenbanken und Cloud-Dienste akzeptieren mittlerweile SPIFFE-Identitäten zur Authentifizierung, sodass keine Datenbankkennwörter oder langlebigen Zugriffstoken mehr erforderlich sind.

Das Schöne daran ist die Einfachheit. Denn am Ende erhalten Unternehmen einen Identitätsmechanismus, der überall funktioniert, automatisch bereitgestellt und rotiert wird – ohne separate Verteilung von Anmeldedaten.

Alternativen zu SPIFFE

Für das Workload-Identity-Management gibt es mehrere Alternativen zu SPIFFE, die je nach Umgebung und Anforderungen ihre eigenen Stärken und Einschränkungen haben:

Cloud-native IAM-Rollen

AWS-IAM-Rollen für EC2/ECS/Lambda, Google-Cloud-Service-Accounts und Azure Managed Identity ermöglichen eine automatische, von Anmeldeinformationen freie Authentifizierung innerhalb ihrer jeweiligen Ökosysteme.

Wenn Sie eine Single-Cloud-Umgebung nutzen und Ihre Workloads nur auf Dienste innerhalb dieser Cloud zugreifen müssen, sind diese Lösungen oft einfacher und besser integriert als SPIFFE. Übrigens verwendet Google für seine verwalteten Workload-Identitäten „unter der Haube" tatsächlich SPIFFE.

Kubernetes-Service-Accounts mit Token-Projektion

Moderne Kubernetes-Cluster können Workloads automatisch mit JWT-Tokens versorgen, die ihre Identität nachweisen. In Kombination mit Service Meshes wie Istio entsteht so ein robustes Identitätssystem ohne zusätzliche Infrastruktur. Allerdings kann SPIFFE innerhalb von Kubernetes auch auf verschiedene Attestierungsmechanismen zurückgreifen, die über Service-Accounts hinausgehen – etwa auf Pod-Metadaten, Node-Informationen oder weiteren Kubernetes-Kontext.

Plattformspezifische Lösungen

Viele Plattformen bieten eigene, integrierte Mechanismen für Workload-Identitäten. GitHub Actions stellt OIDC-Tokens bereit, GitLab CI JWT-Tokens und Cloud Functions erhalten automatisch zugewiesene Identitäten. Diese Ansätze funktionieren gut, solange man innerhalb der jeweiligen Plattformgrenzen bleibt.

Workload Identity Federation

Cloud-Anbieter ermöglichen es, externe Identitäten, zum Beispiel Kubernetes-Service-Account-Tokens, in ihre IAM-Systeme einzubinden. Auf diese Weise lassen sich unterschiedliche Identitätsdomänen miteinander verbinden – ohne dass zwingend SPIFFE erforderlich ist.

Warum also SPIFFE in Betracht ziehen?

Der entscheidende Punkt liegt in den Einschränkungen der Alternativen: Sie sind in der Regel an bestimmte Plattformen, Clouds oder Orchestrierungssysteme gebunden. SPIFFE überzeugt, weil diese Grenzen nicht bestehen und somit mehr möglich wird.

• Isolierung von Identitäten auf Prozessebene: SPIFFE kann Authentifizierungsdaten gezielt an einzelne Prozesse ausgeben – nicht nur an ganze Workloads. Während Cloud-IAM-Rollen und Kubernetes-Service-Accounts in der Regel für jeden Prozess auf einer VM oder in einem Container verfügbar sind, kann SPIFFE einzelne Prozesse verifizieren und authentifizieren. So wird sichergestellt, dass nur autorisierte Anwendungen Authentifizierungsdaten erhalten – auch wenn mehrere Prozesse auf demselben Host laufen.

• Universelle Kompatibilität: SPIFFE ist ein Identitätssystem, das über Clouds, lokale Rechenzentren, Bare-Metal-Server und Edge-Umgebungen hinweg funktioniert. Es funktioniert auf physischen Servern und VMs ebenso zuverlässig wie in Cloud-nativen Umgebungen.

• Plattformunabhängigkeit: Das Framework ermöglicht Workloads, die zwischen unterschiedlichen Orchestrierungssystemen migrieren oder auch komplett außerhalb containerisierter Umgebungen auf Bare-Metal-Infrastruktur betrieben werden.

• Komplexe Multi-Cloud-Szenarien: Anwendungen, die gleichzeitig über AWS, GCP, Azure und lokalen Umgebungen laufen, sind für SPIFFE kein Problem.

• Standardisierte Identität: Das System zur sicheren Authentifizierung von Diensten gilt ebenso als konsistentes Identitätsformat, das von Drittanbieter-Tools universell verstanden wird.

• Benutzerdefinierte Attestation: Mit SPIFFE erhalten Unternehmen die Möglichkeit, eigene Logik zur Verifikation von Workloads zu definieren. Das geht über das hinaus, was Plattformen nativ bereitstellen.

In der Theorie klingt SPIFFE überzeugend. Sie fragen sich bestimmt, wie das in der Praxis aussieht. In unserem Blog haben wir auch die SPIFFE-Erfahrungen gesammelt.

Lass Sie uns sprechen